Use two separate auth cookies to authenticate requests for HTML pages
(these use the pre-existing auth cookie) and requests from h's own
frontend code to h's API endpoints (these use a new, separate API auth
cookie that's introduced by this commit).

This enables the API auth cookie to be more secure. In particular, the
API auth cookie can use SameSite=Strict rather than Lax, which gives
better protection against CSRF attacks but would not be desirable for
the HTML auth cookie (because whenever a user followed a link from
another site to Hypothesis they would find themselves not authenticated).

How this works: `CookiePolicy` (which is used for HTML page requests)
sets and deletes both the HTML auth cookie and the API auth cookie on
log in and log out, but reads only the HTML auth cookie to authenticate
HTML page requests. `APICookiePolicy` reads only the API auth cookie to
authenticate API requests, and never sets or deletes either cookie.

In detail:

1. Recall that the top-level security policy (`TopLevelPolicy`)
   delegates all method calls to either `CookiePolicy` (for HTML
   endpoints) or `APIPolicy` (for API endpoints).

2. When a user logs in the view calls `pyramid.security.remember()`
   which calls `TopLevelPolicy.remember()`. The login form submission
   is an HTML endpoint so `TopLevelPolicy.remember()` delegates to
   `CookiePolicy.remember()` which sets both the HTML and API auth
   cookies.

3. Similarly when the user logs out `CookiePolicy.forget()` deletes both
   the HTML and API auth cookies.

4. To authenticate HTML page requests `CookiePolicy.identity()` reads
   only the HTML auth cookie.

5. To authenticate API requests `TopLevelPolicy` delegates to
   `APIPolicy` which delegates to a list of API subpolicies
   (`BearerTokenPolicy`, `AuthClientPolicy` and `APICookiePolicy`).
   If there's no bearer token or auth client authentication in the
   request then `APICookiePolicy` reads only the API auth cookie
   to authenticate API requests.